Fix jump-to-date being off by one day in non-UTC timezones#14816
Open
fethij wants to merge 1 commit into
Open
Conversation
fethij
force-pushed
the
fix-jump-to-date-off-by-one
branch
from
1bb6adc to
742dc06
Compare
mtang-signal
reviewed
Jun 1, 2026
Contributor
mtang-signal
left a comment
mtang-signal
left a comment
There was a problem hiding this comment.
In general, I'm fine with this change, but I don't think a lot of these comments are necessary and can be removed.
fethij
force-pushed
the
fix-jump-to-date-off-by-one
branch
from
742dc06 to
24f07c1
Compare
MaterialDatePicker reports the selected day, the calendar constraints, and
the validator callbacks in terms of UTC midnight. When reading those values
back, both JumpToDateValidator.normalizeToLocalMidnight() and the date
picker's positive-button handler converted the UTC-midnight instant using
the local zone:
Instant.ofEpochMilli(timestamp).atZone(ZoneId.systemDefault()).toLocalDate()
For any negative UTC offset, the UTC-midnight instant of calendar day D
falls on the previous evening locally, so toLocalDate() yields D-1. As a
result a message sent on local day D became selectable under picker day
D+1 (the reported "selectable dates are one day ahead" symptom), and the
positive-button handler shifted the jump target by a day as well.
Read the calendar day in UTC (matching how MaterialDatePicker emits it),
then re-anchor to local midnight, which is how message days are keyed in
the database (messageExistsOnDays). Add a regression test exercising a
negative-offset zone (America/New_York); it fails before this change and
passes after.
fethij
force-pushed
the
fix-jump-to-date-off-by-one
branch
from
24f07c1 to
f9294d6
Compare
Author
Done! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #14342.
Problem
In the conversation search "jump to date" picker, the selectable dates are one day ahead of the day they actually refer to (e.g. a message sent on 2025-06-20 only becomes selectable under 2025-06-21).
MaterialDatePickerworks entirely in UTC: the selection, the calendar constraints, and theDateValidatorcallbacks are all UTC-midnight timestamps for the displayed calendar day. The picker is set up correctly (LocalDateTime.now().atMidnight().atUTC()), but both places that read a value back reinterpret that UTC-midnight instant in the local zone:JumpToDateValidator.normalizeToLocalMidnight()— decides which calendar cells are selectableConversationFragment— computes where to jumpFor any negative UTC offset, UTC midnight of calendar day
Dfalls on the previous evening locally, sotoLocalDate()returnsD-1. The validator therefore enables dayDfor messages that actually live on local dayD-1(the "one day ahead" symptom), and the jump target is shifted by a day too.The database keys message days by local midnight (
MessageTable.messageExistsOnDays:DATE_SENT >= startOfDay AND DATE_SENT < startOfDay + 86400000), so the correct mapping is: read the calendar day from the picker in UTC, then re-anchor that day to local midnight.Fix
Use
ZoneOffset.UTCwhen extracting theLocalDatefrom the picker timestamp in both read-back paths, keepingatStartOfDay(zoneId)to anchor at local midnight. Both sites must change together so the selectable day and the jump target stay consistent.Testing
Added a regression test to
JumpToDateValidatorTestfor a negative-offset zone (America/New_York): a picker selection of June 15 (UTC midnight) must map to New Yorks June 15, not June 14.Verified locally against the pinned toolchain (
:Signal-Android:testPlayProdDebugUnitTest --tests "*JumpToDateValidatorTest"):10 tests completed, 1 failed(the new test fails —expected to be true).tests="10" skipped="0" failures="0" errors="0".